feat(tracer): report OTLP export status in startup log#5062
Open
bm1549 wants to merge 2 commits into
Open
Conversation
Add three boolean fields to the "DATADOG TRACER CONFIGURATION" startup log indicating whether each telemetry signal is exported over OTLP: - otlp_traces_export_enabled (tracer's cached otlpExportMode, which reflects that CI-Visibility and log-to-stdout writers are selected ahead of the OTLP writer) - otlp_metrics_export_enabled (OTel metrics signal enabled AND the OTLP metrics exporter selected: RuntimeMetricsOtelEnabled() && OTLPExportMetricsMode(); defaults to false, matching the other tracers) - otlp_logs_export_enabled (config LogsOTelEnabled) Update the startup-log golden assertions and clear the OTLP-driving env vars in the test so the expected output is deterministic regardless of shell/CI env pollution. Add a positive case asserting the metrics field is true when the OTel metrics signal and OTLP exporter are both active. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
bm1549
added
the
AI Generated
Contributor
Config Audit |
🎉 All green!🧪 All tests passed 🎯 Code Coverage (details) 🔗 Commit SHA: f3a578b | Docs | Datadog PR Page | Give us feedback! |
This was referenced Jul 24, 2026
BenchmarksBenchmark execution time: 2026-07-24 23:34:47 Comparing candidate commit f3a578b in PR branch Found 0 performance improvements and 0 performance regressions! Performance is the same for 326 metrics, 0 unstable metrics, 1 flaky benchmarks without significant changes.
|
bm1549
marked this pull request as ready for review
July 24, 2026 21:38
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ab2d1374a8
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Comment on lines
+194
to
+195
| OTLPMetricsExportEnabled: t.config.internalConfig.RuntimeMetricsOtelEnabled() && t.config.internalConfig.OTLPExportMetricsMode(), | ||
| OTLPLogsExportEnabled: t.config.internalConfig.LogsOTelEnabled(), |
There was a problem hiding this comment.
When a tracer-only application sets DD_METRICS_OTEL_ENABLED=true or DD_LOGS_OTEL_ENABLED=true, these fields are logged as enabled even though no OTLP exporter may be running: OTel metrics only start when the optional ddtrace/opentelemetry/metric package has registered otelmetricsinstall.StartHook, and the tracer does not start the OTel log integration here. This makes the startup diagnostic claim metrics/logs are exported over OTLP based only on config flags, which can mislead users debugging why no OTLP data is leaving the process; the metric value should at least use the same condition as otelRuntimeMetricsShouldBeEnabled, and logs need an actual integration-started signal rather than just LogsOTelEnabled().
Useful? React with 👍 / 👎.
Derive otlp_metrics_export_enabled in the startup log from otelRuntimeMetricsShouldBeEnabled, the same gate the tracer uses to start OTel runtime metrics, instead of RuntimeMetricsOtelEnabled && OTLPExportMetricsMode. The old predicate over-reported: it logged true even when the opentelemetry/metric package was not imported (StartHook nil) or runtime metrics were off, so no OTLP pipeline was actually running. Logs keep reporting LogsOTelEnabled (config intent) because the user starts the OTel logs integration after the startup log is emitted, so no started-state is knowable at that point. Add a startup-log test for the config-intent-without-pipeline case and update the positive test to install a stub StartHook so the pipeline is genuinely active. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Adds three boolean fields to the "DATADOG TRACER CONFIGURATION" startup log (
startupInfoinddtrace/tracer/log.go) that report whether each telemetry signal is exported over OTLP:otlp_traces_export_enabled: the tracer's cachedotlpExportMode(true whenOTEL_TRACES_EXPORTER=otlpselects the OTLP trace writer, after CI Visibility and log-to-stdout writers have been ruled out)otlp_metrics_export_enabled:RuntimeMetricsOtelEnabled() && OTLPExportMetricsMode()otlp_logs_export_enabled:LogsOTelEnabled()It also updates the
log_test.gogolden assertions for the new fields and clears the OTLP-driving env vars inTestStartupLogso the expected output is deterministic regardless of shell/CI env pollution. A new subtest assertsotlp_metrics_export_enabledis true when both the OTel metrics signal and the OTLP metrics exporter are active.Motivation
Part of a cross-tracer effort to report OTLP export status in the startup diagnostic log using identical JSON keys across the dd-trace-* libraries. These flags make it easy to confirm which signals a service exports over OTLP when diagnosing configuration.
Reviewer's Checklist
make lintlocally. (gofmtclean on both files.)make testlocally. (TestStartupLogand all subtests pass.)make generatelocally. (N/A: no generated files touched.)🤖 Generated with Claude Code
Related PRs — cross-tracer OTLP startup-log effort